A static analysis \cite{Seo:2007:SBD:1522565.1522587}, has been used to find
some default value reads in Java programs, and supports our belief that default
value reads can be found in real programs and should be considered errors.  Our
approach is stronger (detecting all errors at the expense of some correct
programs) and considers additional language constructs that are not present in
Java.

There has been a study on a large body \cite{Gil:2009:WRS:1615184.1615216} of
Java code, showing that initialization order issues pervade projects from the
real world.  A bytecode verification system for Java initialization has also
been explored \cite{Hubert:2010:ESO:1888881.1888890}.

An early work to support non-null types in Java
\cite{Fahndrich:2003:DCN:949305.949332} has the notion of a type constructor
$raw$ that can be applied to object types and means that the fields of the
object (in X10 terminology) may violate the constraints in their types.
Our approach permits optimization of the representation of fields whose types are very
constrained, since they will never have to hold a value other than the values
allowed by their type constraint.

A later work \cite{Fahndrich:2007:EOI:1297027.1297052,XinQi:2009} allows
    to specify the time
    (in the type) when the object will be fully constructed.
Field reference types of a partially constructed objects must be fully
constructed by the same time, which allows graphs of objects to be constructed
like our \code{proto} design.  However the system is more complicated, allowing
the object to become fully constructed at a given future time, instead of at
the specific time when its constructor terminates.
%We did need this functionality.

Masked types~\cite{XinQi:2009} present types that
    describe the exact fields that have not yet been initialized.
Summers and M{\"u}ller~\cite{Summers:Mulller:2011} describe a simpler type system that is almost identical to our \code{proto} design,
    however they only treat non-null types and they allow reading a field before it was assigned.
Our type system is simpler but less expressive because it cannot handle immutable cyclic structures.
%as we only distinguish between the empty set of fields, and some non-empty set of fields.

There is also a time-aware type system \cite{Matsakis:2010:TTS:1869459.1869511}
that allows the detection of data-races, and understands the concept of shared
variables that become immutable only after a certain time
(and can then be accessed without synchronization).  The same mechanisms can also be
used to express when an object becomes cooked.

Ownership types can be used to create immutable cycles~\cite{Zibin:2010:OIG:1869459.1869509}.
This is comparable to
our \code{proto} design because it also allows \code{this} to be linked from an
incomplete object.  However the ownership structure is used to implement a
broader policy, allowing code in the owner to use a reference to its partially
constructed children, whereas we only allow code to use a reference to objects
that are being partially constructed in some nesting stack frame.  Our
approach does not use ownership types.
